A computer system can be generally divided into four components: the hardware, the operating system, the application programs and the users. The hardware (e.g., central processing unit (CPU), memory and input/output (I/O) devices) provides the basic computing resources. The application programs (e.g., database systems, games business programs (database systems, etc.) define the ways in which these resources are used to solve computing problems. The operating system controls and coordinates the use of the hardware resources among the various application programs for the various users. In doing so, one goal of the operating system is to make the computer system convenient to use. A secondary goal is to use the hardware in an efficient manner.
The Unix operating system is one example of an operating system that is currently used by many enterprise computer systems. Unix was designed to be a time-sharing system, with a hierarchical file system, which supported multiple processes. A process is the execution of a program and consists of a pattern of bytes that the CPU interprets as machine instructions (text), data and stack. A stack defines a set of hardware registers or a reserved amount of main memory that is used for arithmetic calculations.
The Unix operating system consists of two separable parts: the “kernel” and the “system programs.” Systems programs consist of system libraries, compilers, interpreters, shells and other such programs that provide useful functions to the user. The kernel is the central controlling program that provides basic system facilities. The Unix kernel creates and manages processes, provides functions to access file-systems, and supplies communications facilities.
The Unix kernel is the only part of Unix that a user cannot replace. The kernel also provides file system, CPU scheduling, memory management and other operating-system functions by responding to “system-calls.” Conceptually, the kernel is situated between the hardware and the users. System calls are used by the programmer to communicate with the kernel to extract computer resource information. The robustness of the Unix kernel allows system hardware and software to be dynamically configured to the operating system while applications programs are actively functional without having to shut-down the underlying computer system.
Thus, when system hardware or software resource changes are implemented in a computer system having the Unix operating system, the kernel is typically configured or reconfigured to recognize the changes. These changes are then made available to user applications in the computer system. The Unix operating system is a robust software that allows network devices to be dynamically connected to the network without having to shut down existing devices on the network. Device auto-configuration is the process by which the kernel loads and attaches device drivers to the devices connecting to the network. Certain kernel implementations perform device auto-configuration on a per-driver basis, i.e., for each driver, all instances of the driver are attached in a single request. This is often referred to as a “bottom-up” loading.
In contrast, other kernel implementations configure devices in a branch of the device tree based on the physical bus slot to which the hardware is connected. This process starts at a bus nexus and drives configuration down the device tree. This process is referred to as a “top-down” loading. Much of the complexity in the Unix operating system I/O framework is related to making dynamic reconfiguration (“top-down” loading) co-operate with device auto-configuration (“bottom-up” loading).
FIG. 1 is a block diagram illustration of an exemplary prior art computer system 100. The computer system 100 is connected to an external storage device 180 and to an external drive device 120 through which computer programs can be loaded into computer system 100. The external storage device 180 and external drive 120 are connected to the computer system 100 through respective bus lines. The computer system 100 further includes main memory 130 and processor 110. The drive 120 can be a computer program product reader such a floppy disk drive, an optical scanner, a CD-ROM device, etc.
FIG. 1 additionally shows memory 130 including a kernel level memory 140. Memory 130 can be virtual memory which is mapped onto physical memory including RAM or a hard drive, for example. During process execution, a programmer programs data structures in the memory at the kernel level memory 140. User applications 160A and 160B are coupled to the computer system 100 to utilize the kernel memory 140 and other system resources in the computer system 100. In the computer system 100 shown in FIG. 1, when kernel events occur, each of the applications 160A and 160B have to independently perform configuration and/or re-configuration operations to become aware of these events. Furthermore, each application has to initiate system calls to the kernel 140 to extract information on a particular device connected to the network.
This typically results in the applications blocking or waiting for the kernel 140 to extract event information. Having the applications 160A and 160B independently issue system calls to the kernel to extract kernel event information further requires the applications to always preempt the kernel to extract event information. This can be inefficient, time consuming and costly. It may also require the applications to terminate or suspend other processes while preempting the kernel to extract kernel event information.
FIG. 2 is a prior art illustration of a computer network having a CPU 110, a bus driver 210, a network driver 220 and memory 140. The network 200 further includes interface devices 230 and 240 that enables SCSI and USB hardware devices and disks to connect to the network 200. The network interface card 220 enables remote devices Resrc 1–N to connect to the network 200.
In the example shown in FIG. 2, the network devices Resrc 1–N and the hardware devices and disks comprise the device tree of the network 200 and each of the devices and disks connect to the network 200 by a single request when the network is activated and the devices are physically connected to the network. The devices are represented in the prior art kernel by a tree of device information nodes, commonly referred to as the kernel device tree. For hardware devices, a parent-child relationship in the device tree often represents a physical topology of how devices are connected.
In traditional Unix systems, such as the Solaris™, the kernel relies on firmware and configuration files (e.g., a registry) to drive device enumeration in the device tree. Firmware enumeration is slow and configuration files are difficult to be kept in synchronization with other hardware configurations. As devices are added to the network 200, all instances of the device are attached per a single request. When this process is pictured in the kernel device tree with leaf nodes on the bottom, the configuration process starts with leaf nodes at the bottom of the tree and percolates upwards.
Usage of resources provided by a device by a user application requires the underlying operating system of the computer system to know all instances of devices for that driver to be able to access the device. As the network expands and more devices are added to it, the requirement of the prior art device configuration illustrated in FIG. 2 becomes cumbersome and difficult to manage as both users and system administrators have to continuously know all the instances of a device attached to the network to be able to access the device. The prior art system shown in FIG. 2, further requires a manual configuration of devices being added to the network subsequent to the computer system boot-up operation.
Furthermore, device configuration in the prior art system shown in FIG. 2 utilizes standard configuration tools for gathering information on the kernel device configuration. These tools rely on a device information snapshot which is a copy of the actual kernel device tree. One problem with these tools is that device information is unavailable if the device driver is not attached to the device. This is typically indicated by a “driver not attached” error message. This problem is not very serious under a bottom-up loading scheme where all instances are attached if at least one driver instance is in use. Typically, a system will use at least one disk and one network interface resulting in all disks and network interfaces (bound to the same driver) to remain attached. Thus, in the prior art network shown in FIG. 2, the user may erroneously be provided with device information on the network even if the requested device is not attached. This can result in network slow-down if a host of detached devices are requested by the application programs and those device do not exist, but still appear to the user as being connected.